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FOREWORD 


The  Comprehensive  Occupational  Data  Analysis  Programs  (CODAP),  a  soft¬ 
ware  package  developed  by  the  United  States  Air  Force,  is  in  use  by  ail  the 
United  States  military  services  and  numerous  other  agencies  throughout  the 
world.  Of  the  two  predominant  versions  of  CO  DAP,  the  IBM  version  has  not 
kept  pace  with  the  continuing  development  of  the  UNIVAC  version. 

In  1978  the  Navy  Occupational  Development  and  Analysis  Center,  a 
detachment  of  the  Naval  Military  Personnel  Command,  and  serving  as  Executive 
Agent  for  Joint  Task  Analysis  Support  for  the  Department  of  Defense,  initi¬ 
ated  a  project  to  develop  an  enhanced  IBM  version  of  CODAP  which  would  be 
less  machine  dependent  than  the  existing  IBM  version,  easy  for  non-program¬ 
mers  to  learn  and  use,  and  which  would  provide  the  capability  to  implement 
new  analysis  approaches  for  analyzing  occupational  data.  The  funding  for 
this  project  was  provided  by  the  United  States  Navy,  Marine  Corps,  and  Coast 
Guard. 

As  a  result  of  this  project,  CODAP80,  an  enhanced  version  of  IBM  CODAP, 
was  developed  by  Texas  AfcM  University.  This  manual  is  one  of  four  CO  DAPS') 
manuals  which  were  developed  to  accompany  the  CODAP80  system.  The  four 
manuals  are  the  CODAP80  Executive  Summary,  the  Job  Analysis  Manual,  the 
User's  Manual,  and  the  Systems  Manual. 
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CODAP80 


INTRODUCTION 


The  CODAP80  occupational  analysis  computer  system  consists  of  two  major 
sets  of  software:  the  software  that  comprises  database  creation,  and  the 
software  that  comprises  the  interpreter.  The  entire  CODAP80  system  is 
written  in  FORTRAN  according  to  the  specifications  outlined  in  the  document 
IBM  System/360  and  System/370.^,  FORTRAN  IV  Language,  order  number 
GC28-6515-10. 

/  CODAP80  was  developed  using  the  IBM  FORTRAN  IV  G1  compiler  (Release 
i  2.0)  operating  under  MVS/JES3  on  an  Amdahl  470/V8  computer,  and  on  an  IBM 
/  370/148  computer  operating  under  VM/SP.  The  system  should  compile  correctly 
/  on  IBM's  H  compiler.  Users  of  the  VS  FORTRAN  compiler  will  find  that 
CODAP80's  interpreter  subroutine  SQUASH  produces  an  underflow  abend 
condition . 


ORGANIZATION  OF  THE 
SYSTEMS  MANUAL 

The  Systems  Manual  is  organized  into  two  major  sections:  database 
creation  and  the  interpreter.  The  characteristics  and  attributes  of  the  two 
system  sections  is  discussed,  with  subroutines  being  identified  and  file 
layouts  displayed.  All  file  layouts  pertain  to  the  data  to  be  found  in  the 
sample  set  of  data  introduced  in  the  User's  Manual.  The  operation  of  the 
CODAP80  interpreter  is  outlined,  as  well  as  token  recognition  and  the  access 
and  retrieval  of  database  information ./\  File  space  calculation  equations  for 
the  different  routines  in  the  CODAP80I  system  can  be  found  in  the  User's 
Manual.  JCL  execution  setups  for  the  CODAP80  system  may  also  be  found  in 
the  User's  Manual. 


CODAP80  RELEASE 

The  specifications  outlined  in  the  Systems  Manual  pertain  to  the  83.1 
release  of  CODAP80. 
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THE  DATABASE  CREATION 
ROUTINES 

INTRODUCTION 


The  database  creatioh  routines  consist  of  the  programs  INPSTD,  OGROUP 
and  REARNG.  All  three  of  these  programs  execute  in  under  5I2K  bytes  of 
memory . 


INPSTD 

The  INPSTD  database  creation  routine  is  the  primary  input  routine  for 
all  the  data  of  an  occupational  study.  Files  unique  to  the  INPSTD  routine 
are: 


CONTROL  -  FT03F001 
INPFILE  -  FT02F001 
DATA  -  FT04F001 
VARCOM  -  FT10F001 
SYMTAB1  -  FT12F0Q1 
DECODE  -  FT17F001 


CONTROL 

Data  set  CONTROL  is  a  card  image  sequential  file  containing  remarks  for 
the  history,  task  and  secondary  variables,  as  well  as  decode  titles  and  for¬ 
mat  fields  specifications.  On  CODAP80's  host  computer,  it  was  blocked 
FB/80/6160.  The  exact  layout  of  the  CONTROL  file  can  be  found  in  Appendix 
B. 


INPFILE 

Data  set  INPFILE  is  a  direct  access  file  with  3600  byte  records.  Fol¬ 
lowing  execution  of  the  INPSTD  database  creation  routine,  it  contains  the 
incumbent  history,  task  (relativized)  and  secondary  data.  Following  the 
incumbent  data  are  two  words  containing  the  sum  of  the  row  time  spent 
responses  from  the  incumbent  and  the  number  of  nonzero  responses  to  tasks. 
The  layout  of  INPFILE  after  SAMPLEDATA80  INPSTD  execution  may  be  found  in 
Appendix  B. 


DATA 

Data  set  DATA  is  a  card  image  sequential  file  containing  the  raw  incum¬ 
bent  responses  to  history,  task  and  secondary  indicies.  The  information  in 
this  data  set  is  processed  by  INPSTD  and  written  to  data  set  INPFILE.  On 
CODAP80's  host  computer,  it  was  blocked  FB/80/6160.  The  exact  layout  of  the 
DATA  file  can  be  found  in  Appendix  B. 
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VARCOM 


Data  set  VARCOM  is  a  direct  access  file  with  244  byte  records.  Follow¬ 
ing  execution  of  the  INPSTD  database  creation  routine,  it  contains  the  his¬ 
tory,  task  and  secondary  remarks  that  were  processed  from  the  CONTROL  file. 
The  first  word  of  the  VARCOM  file  contains  the  length  in  characters  of  the 
remark,  and  words  2-61  contain  the  variable  remark  stored  in  packed  format 
(A4).  The  layout  of  VARCOM  after  SAMPLEDATA80  INPSTD  execution  can  be 
found  in  Appendix  B. 


SYMTAB1 

Data  set  SYMTAB1  is  a  direct  access  file  with  48  byte  records.  It  is 
the  inital  symbol  table  and  contains  pointer  values  and  data  counts.  It 
serves  primarily  as  input  to  the  OGROUP  and  REARNG  database  creation  rou¬ 
tines.  The  layout  for  SYMTAB1  can  be  found  in  Appendix  B. 


DECODE 

Data  set  DECODE  is  a  direct  access  file  with  120  byte  records.  It 
contains  the  decode  titles  that  were  processed  from  CONTROL  by  INPSTD.  The 
file  can  be  thought  of  as  a  pseudo-indexed  sequential  file.  See  Appendix  B 
•  for  the  layout  of  the  DECODE  file. 


INPSTD 

SUBROUTINES 

A  listing  of  the  INPSTD  subroutines  may  be  found  on  page  5. 


OGROUP 

The  OGROUP  database  creation  routine  is  the  main  clustering  routine  in 
the  COAP80  system.  Files  unique  to  OGROUP  are: 

GRPFILE  -  FT15F001 
GRPHSN  -  FT16FQ01 


GRPFILE 

Following  execution  of  the  OGROUP  database  creation  routine,  the 
GRPFILE  contains  all  the  resultant  information  from,  the  incumbent  cluster¬ 
ing.  GRPFILE  is  a  direct  access  file  with  records  of  12960  bytes.  Between 
and  within  overlap  values  reside  in  GRPFILE,  as  well  as  the  colapsing  proc¬ 
ess  for  the  diagram.  See  Appendix  B  for  the  configuration  of  GRPFILE. 
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GRPHSN 


Data  set  GRPHSN  is  a  direct  access  file  with  records  of  40  bytes.  Each 
word  of  a  record  corresponds  to  an  incumbent,  and  contains,  positionally, 
the  HSN  location  an  incumbent  should  have.  GRPHSN  acts  as  input  to  the 
REARNG  database  creation  routine.  See  Appendix  B  for  the  layout  of  file 
GRPHSN. 


OGROUP 

SUBROUTINES 

A  listing  of  the  OGROUP  database  creation  subroutines  can  be  found  on 

page  6. 


REARNG 

The  REARNG  database  creation  routine  transposes  the  incumbent  data  in 
INPFILE  so  that,  instead  of  a  record  holding  all  the  variables  for  an  incum¬ 
bent,  a  record  holds  all  the  incumbents  for  a  variable.  If  OGROUP  was 
executed,  then  the  incumbents  in  a  record  are  in  HSN  order.  Files  unique  to 
REARNG  are: 


DATABASE  -  FT01F001 
SYMTAB2  -  FT13F001 


DATABASE 

Data  set  DATABASE  is  a  direct  access  file  with  records  of  4000  bytes. 
The  layout  of  the  DATABASE  file  is  as  follows: 

History  variables  will  be  written  first.  They  will  be  unpacked  Ci.e., 
each  incumbent  has  a  value)  and  will  be  number  of  incumbents  (N1NC)  words 
long. 


Task  variables  will  be  written  in  the  first  word  of  the  record  that 
follows  immediately  after  the  end  of  the  history  variables.  Task  variables 
will  be  written  in  packed  format  (i.e.,  missing  values  are  to  be  removed). 
Secondary  variables  will  start  in  the  word  that  immediately  follows  the  last 
word  of  the  last  task  variable.  Secondary  variables  will  be  written  in 
packed  format. 

The  task  variable  membership  vectors  will  begin  in  the  first  word  of 
the  record  that  follows  the  last  secondary  row.  The  task  membership  vectors 
will  contain  real  numbers  ranging  from  1  to  9.  The  secondary  variable  mem¬ 
bership  vectors  will  begin  in  the  word  that  immediately  follows  the  last 
word  of  the  last  task  membership  vector. 

Following  the  task  and  secondary  membership  vectors  are  the  tables, 
that  define  the  locations  of  the  task  or  secondary  row  vectors  and  their 
associated  membership  vectors.  Each  row  has  two  entries  in  the  table.  The 
first  entry  for  a  row  consist  of  the  number  of  the  record  (relative  to  the 


CODAP80  INPSTD  SUBROUTINES 
ENTRY  POINT  IS  MAIN1 
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CODAP80  OGROUP  SUBROUTINES 
ENTRY  POINT  IS  MAIN2 
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start  of  the  task  rows)  that  the  row  begins  in  times  1000,  plus  the  number 
of  words  to  skip  from  the  start  of  the  record  to  reach  the  first  word  of  the 
row.  The  second  entry  in  the  table  consists  of  the  length  of  the  row  in 
words. 

The  table  for  the  task  rows  will  begin  in  the  first  word  of  the  next 
record  after  the  secondary  membership  vectors.  The  table  will  be  Ntask  *  2 
words  long  and  will  span  (Ntask*2-1)/1000+1  physical  records.  The  table  for 
the  secondary  rows  will  begin  in  the  first  word  of  the  record  that  immedi¬ 
ately  follows  .the  end  of  the  task  table.  The  secondary  table  will  be  NSEC*2 
words  long  and  will  span  (NSEC*2-1)/1000+1  physical  records. 

Following  the  tables  the  system  rows  Rawsum  and  Nonzero  will  appear. 
Each  of  these  rows  will  be  NINC  words  long  and  will  span  (NINC-U/1000+1 
physical  words.  Each  rows  will  start  in  the .  first  word  of  a  physical 
record. 

The  layout  of  file  DATABASE  following  execution  of  the  REARNG  database 
creation  routine  on  the  SAMPLEDATA80  data  can  be  found  in  Appendix  B. 


REARNG 

SUBROUTINES 

A  listing  of  the  REARNG  database  creation  subroutines  can  be  found  on 
the  following  page. 


CODAP80  REARM G  SUBROUTINES 
ENTRY  POINT  IS  MAIN  3 
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THE  CODAP80  INTERPRETER 


The  CODAP80  INTERPRETER  is  used  to  process  and  display  information 
residing  on  a  CODAP80  database.  The  amount  of  memory  required  to  execute 
the  interpreter  is  820K  bytes  ( non-overlay ed ) . 


CODAP80  ERRORFIL 

The  first  step  in  installing  the  interpreter  is  to  generate  the  error 
file.  On  the  following  pages  are  the  CODAP80  error  messages  and  a  FORTRAN 
program  CERRORCVT)  that  will  take  the  error  messages  and  generate  the  error- 
ffl. 


CODAP80  INTERPRETER 
SUBROUTINES 

On  page  13  can  be  found  a  listing  of  the  CODAP80  interpreter 
subroutines . 


INTERPRETER 

OVERVIEW 

The  function  of  the  interpreter  is  to  input  CODAPSO  source  code  state¬ 
ments,  ensure  that  they  are  syntactically  correct,  and  then  perform  the 
operations  indicated  by  the  statements.  The  first  phase  of  the  interpreter, 
the  syntax  analyzer  and  symbol  table  builder  (SYNSYM),  involves  analyzing 
the  syntax  of  the  statements  to  ensure  that  they  are  correct,  and  translat¬ 
ing  the  source  code  into  an  intermediate  form  more  suitable  for  computer 
processing.  The  inputs  to  the  interpreter  used  by  this  phase  are  the 
CODAP80  source  code,  and  the  permanent  symbol  table  (PST,  which  tells  where 
all  permanently  stored  information  is  located;  the  outputs  of  this  phase  are 
an  echo  print  of  the  source  code  and  any  appropriate  error  messages,  inter¬ 
mediate  printing  for  use  by  maintenance  programmers,  an  intermediate  form  of 
the  source  code  which  is  a  stack  with  a  numeric  representation  of  the  source 
code  and  tables  for  symbols,  strings,  and  constants.  The  second  phase 
(EXECUT)  carries  out  the  operations  on  the  data  specified  by  the  CODAP80 
commands.  Its  inputs  are  the  stack  with  the  numeric  representation  of  the 
source  code,  the  three  tables,  the  PST,  the  permanent  data  files,  scratch 
files,  and  data  (if  any)  for  the  INPUT  command.  Its  output  are  additions  to 
the  PST  and  permanent  data  files  and  printed  reports. 

Additional  inputs  to  SYNSYM  that  come  from  the  main,  routine  are  an 
array  to  build  the  stack  of  numeric  tokens,  storage  space  to  build  the  work¬ 
ing  symbol,  string,  and  constant  tables  in,  and  two  variables  SUCCES,  and 
PRTLVL  (print  level).  The  storage  space  for  tables  is  used  to  produce  the 
Working  Symbol  Table  (WST),  the  string  table,  and  the  constant  table.  The 
WST  is  used  to  keep  track  of  all  variables  used  within  a  given  run.  If  the 
variable  exists  on  the  PST  it  is  copied  into  the  WST,  if  it  is  not  on  the 
PST  a  new  entry  for  it  is  made  in  the  WST.  In  this  way  all  variables  that 
are  accessed  within  a  run  can  be  located  via  the  core  resident  WST.  The 


ERROR  MESSAGES 

CODAP80  INTERPRETER  ERROR  MESSAGES 


001  UNRECOGNIZABLE  CHARACTER. 

002  STRING  EXCEEDS  240  CHARACTERS. 

003  unrecognizable  token. 

004  invalid  relational  operator. 

005  invalid  boolean  operator. 

006  INVALID  system  variable. 

007  too  many  symbols  used. 

008  NUMBER  OF  TOKENS  IN  SOURCE  CODE  EXCEEDS  STACK  SIZE. 
009  INTEGER  PORTION  OF  SYSTEM  VARIABLE  TOC  LARGE. 

010  RESERVEO  FOR 
Oil  MORE  MESSAGES 
012  “ROM  GTOKSN 
013  EXPECTING  A  COLUMN. 

014  10  NOT  PREVIOUSLY  OEFINED. 

015  EXPECTING  A  "ROWS"  OR  "COLUMNS"  KEYWORD. 

016  EXPECTING  A  "FOR"  KEYWORD. 

017  A  RESERVEO  WORD  HAS  SEEN  USED  FOR  A  VARIABLE  NAME. 
018  EXPECTING  ASSIGNMENT  OPERATOR. 

019  AN  INVALID  FUNCTION  HAS  BEEN  SPECIFIED. 

020  REMARK  NOT  FOUND 
021  LEFT  PAREN  MISSING. 

022  UNBALANCED  PARENTHESES. 

023  INVALID  VARIABLE  NAME. 

024  AN  ILLEGAL  Range  STATEMENT  HAS  BEEN  SPECIFIED. 

025  A  GROUP  NAME  HAS  NOT  BEEN  SPECIFIED. 

026  A  MODULE  NAME  has  NCT  BEEN  SPECIFIED. 

027  EXPECTING  AN  “ON"  KEYWORC. 

028  EXPECTING  UNDEFINED  ID. 

029  EXPECTING  A  ROW. 

030  EXPECTING  AN  “IN"  KEYWORC. 

03i  EXPRESSION  NOT  ENCLOSSO  IN  PARENTHESES. 

032  INVALID  syntax. 

033  VARIABLES  OUT  OF  SEQUENCE. 

034  "BEGIN"  NCT  FIRST  STATEMENT. 

035  SYSTEM  VARIABLE  NOT  VALID  HERE. 

036  EXPECTING  “USING"  KEYWORD. 

037  A  SINGLE  VALUED  VARIABLE  OR  CONSTANT  IS  EXPECTED. 
038  RELATIONAL  OPERATOR  NOT  VALID  HERE . 

039  EXPECTING  A  SYSTEM  COLUMN. 

040  EXPECTING  HISTORY  VARIABLE  IN  SEQUENCE. 

041  EXPECTING  TASK  VARIABLE  IN  SEQUENCE. 

042  EXPECTING  SECONDARY  VARIABLE  IN  SEOUENCE. 

043  EXPECTING  “FORMAT"  KEYWORD. 

044  EXPECTING  FORMAT  STATEMENT . 

045  THRU  NOT  VALID  HERE. 

046  EXPECTING  SYSTEM  ROW. 

047  EXPECTING  "THEN". 

048  MULTIPLE  CREATES  NOT  ALLOWED  IN  “IF“. 

049  EXPECTING  “ELSE". 

050  EXPECTING  A  PERIOD. 

051  EXPECTING  A  COMMAND  KEYWORD. 

052  EXPECTING  RELATIONAL  OPERATOR. 

053  "+"  ONLY  OPERATION  ALLOWED  HERE. 

054  NOT  A  VALID  KEYWORD  FOR  THIS  COMMAND. 

055  STUDY  ID  DOES  NOT  AGREE  WITH  DATA  BEING  ACCESSED. 
056  A  COLUMN  DESIGNATION  NOT  VALID  HERE. 

057  A  GROUP  DESIGNATION  NOT  VALID  HERE. 

058  UNRECOGNIZED  ID. 

059  EXPECTING  SINGLE  VALUE  VARIABLE. 

060  EXPECTING  SYSTEM  COLUMN  IN  SEOUENCE. 

061  EXPECTING  SYSTEM  GROUP  IN  SEOUENCE. 

062  EXPECTING  SYSTEM  COLUMN  OR  SYSTEM  GROUP. 

063  INVALID  SYNTAX  *0R  A  MODULE  LIST. 

064  EXPECTING  RIGHT  PAREN. 

065  EXPECTING  "HEACING*  KEYWORD. 


ERROR  MESSAGES 

CODAP80  INTERPRETER  ERROR  MESSAGES 
(continued) 


065  HEADING  STRING  CANNOT  EXCEED  131  CHARACTERS. 

067  this  function -has  seen  specified  more  than  once 

063  EXPECTING  FUNCTION  SPECIFICATION. 

069  BOTH  THE  VERTICAL  ANO  HORIZONTAL  AXES  CONSIST  OF  THE-  SAME  0A7A 
070  EXPECTING  "BY*  KEYWORD . 

071  EXPECTING  CHARACTER  STRING. 

072  NO  MORE  THAN  10  TITLE  LINES  MAY  BE  REOUESTEO. 

073  EXPECTING  "COLUMNS"  OR  "COLS"  KEYWORD. 

074  EXPECTING  "ROWS"  KEYWORD. 

075  EXPECTING  KEYWORD  TO  SPECIFY  OVERLAPPING  ALGORITHM. 

076  EXPECTING  "MAXIMIZE"  SPECIFICATION. 

077  EXPECTING  "HSN"  KEYWORD. 

078  EXPECTING  "LOHSN"  KEYWORD. 

07S  EXPECTING  "HIHSN"  KEYWORD. 

oao  expecting  heaoing  string  or  perioo. 

08 1  EXPECTING  HEAOING  STRING. 

082  EXPECTING  "SIMCOF"  KEYWORD. 

oes  expecting  -within"  keyword. 

084  expecting  new  id. 

099  CHECK  syntax  FOR  A  CORRECT  KEYWORD  (EITHER  "ROWS"  OR  "COLUMNS" 

152  NC  MEAN  OR  STANOARO  DEVIATION  FOUND. 

153  ASSIGNMENT  OPERATOR  IS  MISSING. 

154  EXPECTING  A  constant. 

155  REPEATED  "MEAN" . 

156  REPEATED  "STD" . 

157  "STO"  IS  MISSING. 

158  "MEAN"  IS  MISSING. 

159  AN  ASSIGNED  VALUE  OF  STD  MUST  N0T  BE  LESS  Than  ZERO. 

160  TOKEN  IS  NOT  A  CREA7E0/SYS7EM  ROw/CDLUMN/MODULS/GRDUP 

161  MUST  aE  TVARS/HVARS/SVARS/TASKS  ONL" . 

162  LENGTH  OF  CREATED  ROW/COLUMN/MOOULE /GROUP  MUST  BE  GREATER  THAN 

163  NTASK  »  0.  CAN'T  GENERATE  ROWS. 

164  NHIST  «  0.  CAN'T  GENERATE  ROWS. 

165  NSEC  »  0.  CAN'T  GENERATE  ROWS. 

166  NINCS  «  0.  CAN'T  GENERATE  ROWS. 

170  "TAPE"  OR  "CARO"  KEYWOHO  IS  MISSING  IN  COPY  COMMAND. 

171  "3" . "BINARY" . "D* . "DISTANCE" . "02" . "DSOUARE " , "OVL" , OR  "OVERLAP" 

172  "MINMEM"  OR  "HEAOING"  IS  EXPECT  HERE. 

173  "RESET"  MUST  BE  PRECEEDED  3Y  "NOSKIP". 

174  "CUM"  OR  "COUNT"  MUST  BE  PRECEEDED  BY  "NOSKIP "3 "RESET "  RESPECT 

175  MINMEM  MUST  BE  EOUAL  OR  GREATER  THAN  2. 

18C  EXPECTING  "N"  IN  ADOATA  COMMANO . 

181  EXPECTING  "N*"  OR  "N:*"  BEFORE  A  CONSTANT. 

182  REPEAT  FACTOR  MISSING  IN  ADOATA  COMMAND. 

183  EXPECTING  *•*  OR  *:•" 

184  A  CONSTANT  IS  MISSING  IN  AODATA  COMMAND. 

185  "(“  MISSING. 

186  UNRECOGNIZED  TOKEN  IN  ADDATA  COMMANO. 

187  A  CONSTANT  MISSING  FOLLOWING  A  OASH  (-). 

188  ")"  MISSING  FOLLOWING  A  CONSTANT  LIST. 

189  THE  VALUE  OF  N  ANO  NUMBER  OF  CREATED  ICS  ARE  NOT  THE  SAME. 

190  NUMBER  OF  NUMERIC  FIELDS  IN  fqRMAT  MUST  BE  1000  OR  LESS. 
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ERROR CVT 

PROGRAM  TO  GENERATE  THE  INTERPRETER  ERROR  FILE 


/,'  EXEC  FG.REGICN*256K 
//FTCIFOOi  00  0SN.*ERR0RS.DISP*0L0 

//FT02F001  DO  DSN*ERRORPI L . UNIT. SYSDA , DI SP* ( NEW , CATLG ) , 
//  DCS* (0S0RG*0A). SPACE *(320. (150.1;) 

//SOURCE  00  - 


C  ERROR  FILE  PROGRAM  ( ERRORCVT )  . 

C  PROGRAM  TO  GENERATE  THE  ERROR  FILE  FOR  THE 
C  C00AP8O  INTERPRETER.  THE  ERRORS  (IN  CARD  IMAGE 
C  FORM)  ARE  READ  FROM  FILE  1  AND  WRITTEN  TO 
C  FILE  2  ( OSORG'CA ) . 

C - 

DEFINE  FI.E  2  (  150,80. li.  IREC) 

INTEGER  IE RR(SO> 

DATA  j/1/ 

1  •  J»U*1 

00  2  1*1 ,60 

2  I  ERR ( I  ;  *0 
00  3  1*1,80 

fl£AD< 1. lOi.ENC*iOC)  IERRII) 

101  FORMAT! 13,  IX. TSAI  I 

3  CONTINUE 
IREC-o 

WRITE  I  2 ' IREC  )  I  ERR 
GO  TO  1 

IOC  I F ( I  .  EQ . 1 )  GO  TC  200 
IREC*u 

WRITS( 2 ' IREC •  I  ERR 

200  NUMFaR.(u-2)*B0*l-’ 

IRECST  *u- 1 

IF ( I  FC. ’ I  IRECST. IRECST-1 
WRITE ( 2 ' 1 )  NUMERR. IRECST 
IREC-IRECST 
HEWINO  i 

201  REAO( 1 . ‘01 ,END*300)  ( I ERR( I ) . I • * . TT ! 

WRITE(2' IREC!  t!SRR(I).I«1.?7) 

GO  TC  201 

300  REAO( 2 ' 1 )  NUMERR. IRECST 

WRITE (6,6011  NUMERR, IRECST 
K-IRECST-1 
00  A0 1  I*2.K 
IREC* I 

REAO( 2 ' IREC  )  IERR 
WRITE(6 , SOI )  IERR 

501  eORMAT( IX, ( IX, 3014  I ) 

401  CONTINUE 

I TREC •NUMERR* IRECST-  1 
00  402  I • IRECST , ITREC 
IREC* I 

READ ( 2 ' IREC  )  t I ERR( K ) , K* 1 , 77 ) 

WRITE(S,502)  ( I £RR( K  ) . K» 1 . 77 ) 

502  FORMAT( IX, 14, 1X.7SA1  ) 

402  CONTINUE 
STOP 
END 

//SYSIN  00  • 


Reproduced  from 
best  available  copy. 


/r 
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CODAP80  INTERPRETER  SUBROUTINES 
ENTRY  POINT  IS  MAIN4 


ACCMOD 

CORRPM 

GROUP 

PCNT A V 

RELYCO 

ADD ATE 

CORRPR 

GROUPS 

PCNTC 

RELYE 

AOOATS 

CORRRM 

GRPCHK 

PPtINC 

RELYS 

ADDCON 

CORRRT 

GRPIT 

P FUNC A 

RELYSM 

AOOID 

CORPS 

GRPLST 

PFUNCC 

RELYSS 

AODREM 

CREATE 

GTCHAR 

PFUNCR 

REPCRE 

AOOSTR 

CHEATS 

GTOKEN 

PICKSG 

REPORE 

ALLCOR 

CRELEX 

HASH 

POP 

REPORS 

ALPHA ' 

CTBMAN 

HEADNG 

POPIT 

RETCCR 

ARITHE 

CTRIPS 

HSNFO 

POSTFX 

RETCNS 

ASSIGN 

cumlst 

ID 

PR  ALL 

RETGM 

AVALUE 

DATINT 

IOCR 

pralls 

RETLT1 

AVALUS 

DECODE 

IDENTg 

PRFORM 

RETLT2 

AVGA 

OELIM 

IDENTS 

PRHEAD 

RETMEM 

AVGAAV 

OESCRE 

I  GET 

PRHORZ 

RETPOS 

AVGAC 

OESCRS 

INFMT 

PRINTE 

RETRC 

AVGP 

OIAGRS 

INITD 

PRINTS 

RETSW 

AVGPAV 

DIGIT 

INITK 

PRLOAO 

RETTRP 

AVGPC 

DIGRAM 

INITLZ 

P9S0RT 

RLIST 

BACKUP 

OOROW 

INPUTS 

PRSVV 

ROW 

BEGINE 

ECOOE 

INPUTS 

PRTCT 

ROWCHK 

BEGINS 

ENOE 

INRPRN 

PRTMSG 

ROWNUM 

BINSRC 

ERRPRT 

inunpk 

PRTPST 

RPCRHD 

BLDTRP 

EXECOM 

ITOA 

PRTRVE 

RPCRNR 

BLDWST 

EXECTR 

KEYWRO 

PRTST 

RPCRRM 

BOOLOP 

EXECUT 

KOUNT 

PRTV12 

RPSYCT 

BUILOM 

FILLST 

MAIN4 

PRTWST 

RPSYGP 

CALCSP 

FILLWC 

MODCHK 

PRVTRK 

RPSYMO 

CALCW 

FILLX 

MOO L ST 

PSETUP 

RPSYRW 

CBOOL 

FINOXP 

MOOULE 

PSTAOD 

RRELEX 

CLIST 

F1XMAX 

MROWL T 

PSTEND 

rtoa 

CLUST 

FMAX 

N 

PTOKEN 

RTOPND 

cluste ' 

FPA 

NAV 

PUSH 

RTRWRC 

CLUSTS 

FRMATR 

NC 

PUSHBS 

RTSCOL 

CNEWVC 

froost 

NO I GIT 

PUSHIT 

RTTRIP 

CNSTNT 

FSERCH 

NEWID 

PUSHPT 

RTVTOK 

COLCHK 

FSORT 

NUMF 

PUSHRP 

SAVHSN 

COLERR 

FULLAS 

NUMI 

PUSHRT 

SELECE 

COLNUM 

FUNC 

0GET1 

PUTD 

SELECS 

COLUMN 

GCOLST 

OPUT1 

RANOK 

SETSTK 

COMENT 

GETO 

OUTA 

RANOMK 

SHIFTR 

CONTOK 

GETRAW 

OUTD 

RANOOE 

SHOWA 

COPYE 

GETW 

OUTFO 

RANOOS 

SHQWM 

COPYE1 

GMLEN 

OVLGET 

RANOU 

SIMLAR 

COPYE2 

GMRCCT 

OVLPUT 

RBOOL 

SINVAL 

COPY IN 

GRABH 

PA 

ROISK 

SKIP 

COPYS 

GRABR 

PAIO 

ROISKL 

SNVAL2 

COP2PM 

GRABS 

PASORT 

RELATE 

SORTID 

CORRE 

GRABT 

PBLOCK 

RE  LOP 

SORTLS 

CORRLT 

GRA6X 

PCNT 

RELYAC 

SQUASH 
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SRELEX 

STOA 

STOAAV 

STDAC 

STDE 

ST0E1 

STOE3 

STDP 

STDPAV 

STOPC 

STDS 

STRING 

STRIPS 

STRLEN 

STRRET 

SUM 

SUMAV 

SUMC 

SYNANL 

SYNSYM 

SYNTAX 

SYSVAR 

TCOUNT 

TRANSA 

TRANSB 

TRIPLS 

TRNSPS 

VARHD 

VARSUE 

VARSUS 

VARSU2 

VECWRT 

WOISK 

WDISKL 

WRTRVE 

MRTV12 

WSETUP 

W$T  ADD 

WSTREP 

WSTR12 

WSTSUB 


J  ^ 


string  and  constant  tables  are  used  to  collect  strings  and  constants. 
SUCCES  is  a  variable  that  indicates  if  any  errors  are  found.  It  is  set  to  1 
when  passed  to  SYNSYM.  If  an  error  is  found  it  is  set  to  0.  This  means 
that  if  SUCCES  is  0  on  return  from  SYNSYM  an  error  was  found;  so  EXECUT  is 
not  called.  PRTLVL  is  a  variable  that  will  allow  a  maintenance  programmer 
to  get  extra  information  printed  out  that  should  help  in  modifying  the  sys¬ 
tem.  If  set  to  2  only  the  source  code  and  error  messages  are  printed  out. 
PRTLVL  will  be  set  to  2  for  normal  execution.  If  PRTLVL  is  1  the  PST  is 
printed  first,  then  the  echo  print  of  the  source  code  and  error  messages, 
followed  by  the  WST,  the  string  table,  and  the  constant  table.  If  PRTLVL  is 
0  all  the  previous  information  will  be  printed  plus  the  numeric  value  of 
each  parameter  will  be  printed  as  it  is  recognized. 

SYNSYM  first  calls  IDENTS  to  identify  the  next  command  and  returns  an 
associated  number.  Based  on  this  number  SYNSYM  calls  one  of  the  syntax 
analysis  routines.  The  routine  called  will  analyze  the  syntax  of  a  particu¬ 
lar  command.  If  the  number  indicates  the  END  command  was  found,  SYNSYM 
returns  to  the  main  routine.  Each  of  the  syntax  analysis  routines  calls  a 
subroutine,  which  gets  the  next  parameter  of  the  source  code  and  returns  its 
numeric  representation,  several  times  checking  for  invalid  syntax  or  until  a 
period  is  found  and  then  returns.  When  errors  are  found  ERRPRT  is  called  to 
print  the  message  and  set  SUCCES  to  0.  ERRPRT  will  print  a  dollar  sign 
under  the  last  character  of  the  parameter  in  error  and  the  message  on  the 
next  line.  Whenever  possible  syntax  analysis  is  resumed  after  finding  an 
error,  but,  if  not  possible,  parameters  are  skipped  until  a  period  is  found, 
then  a  return  is  made. 

The  basic  unit  that  the  syntax  analysis  routines  work  with  is  the 
token.  The  parameters  of  commands  are  tokens.  A  token  is  the  smallest 
meaningful  aggregate  of  characters.  For  example:  CREATE  ROW  FOR  G3 
FRED:=A+3  ’remark',  has  11  tokens.  They  are  CREATE,  ROW,  FOR,  G3,  FRED, 
A,  +,  3,  'remark',  and  GTOKEN  (Get  Next  Token)  is  the  routine  that 
picks  these  out  of  the  source  code  and  assigns  a  numeric  value.  For  ids, 
constants,  and  strings  some  information  is  put  into  tables,  the  numeric  code 
points  to  the  proper  position  in  the  tables.  Tokens  from  150000  to  159999 
represent  ids  and  point  to  positions  in  the  WST.  The  ids  are  added  using  a 
hashing  scheme.  Tokens  from  20000  to  29999  point  to  the  constant  table. 
Tokens  from  10000  to  19999  point  to  the  string  table. 

Rows,  columns,  groups,  and  modules  will  all  be  stored  as  records  on  the 
same  file. 

The  EXECUT  phase  is  broken  down  very  similarly  to  SYNSYM.  IDENTE  is 
first  called  to  identify  a  command.  Based  on  the  number  IDENTE  returns,  one 
of  the  execution  routines  is  called.  The  execution  routines  do  whatever 
data  manipulation  is  required  then  return.  The  execution  routines  do  not 
update  the  permanent  files  or  PST..  Any  information  they  generate  is  stored 
on  scratch  files.  When  the  END  command  is  reached  the  data  and  entries  of 
the  WST  that  are  to  be  added  to  the  permanent  information  are  copied  over. 
This  means  that  if  a  power  failure  or  some  problem  occurs  in  the  middle  of 
EXECUT,  the  CODAP80  program  can  be  rerun  with  no  problem,  since  the  perma¬ 
nent  information  has  not  been  changed.  If  something  happens  after  the  END 
oommand  is  found,  while  the  scratch  files  are  being  copied  over,  a  separate 


program  that  does  just  the  copying  over  can  be  run,  since  the  scratch  files 
should  remain  intact  for  a  while.  This  means  there  is  never  any  reason  to 
have  to  restore  the  database  to  a  previous  state  so  that  a  rerun  can  be 
made. 


TOKEN 

RECOGNITION 

The  tokens  of  the  language  are  recognized  by  GTOKEN  (Get  Next  Token). 
GTOKEN  recognizes  tokens  without  regard  to  context.  Because  the  language 
requires  a  blank,  comma,  or  delimiter  between  tokens,  there  is  never  a  case 
where  GTOKEN  has  to  be  aware  of  what  the  previous  or  succeeding  token  is,  in 
order  to  recognize  a  token.  It  is  never  necessary  to  scan  more  than  one 
character  ahead  of  a  token  in  order  to  recognize  that  token.  Because  the 
cards  with  the  source  code  on  them  are  syntax  analyzed  as  they  are  read  in, 
it  is  not  possible  to  back  up  from  the  beginning  of  a  card  to  the  end  of  the 
previous  card.  This  means  that  strings,  comments,  and  constants  are  the 
only  tokens  that  may  cross  card  boundaries,  since  they  can  be  identified 
from  the  first  character. 

The  inputs  to  GTOKEN  are  the  source  code,  the  variables  PRTLVL,  SUCCES, 
ACTUAL,  and  LENGTH,  the  PST,  and  storage  space  for  the  WST,  string  table, 
constant  table,  and  stack  of  numeric  tokens.  TOKEN  is  used  to  return  the 
numeric  code  for  the  token.  ACTUAL  is  used  to  return  the  source  code  token 
when  the  token  is  an  id.  LENGTH  is  used  to  return  the  number  of  characters 
in  the  id.  The  outputs  are  an  echo  print  of  the  source  code  and  any  error 
messages  about  invalid  tokens,  a  printout  of  the  numeric  token  if  called  for 
by  PRTLVL,  another  string,  constant,  or  id  in  the  appropriate  table,  the 
numeric  token  in  the  stack,  TOKEN,  SUCCES,  LENGTH,  and  ACTUAL. 

GTOKEN  is  broken  down  into  several  subroutines.  The  first  series  of 
routines  called,  attempt  to  recognize  a  token  from  the  source  code.  The 
parameter  FOUND  is  passed  to  each  of  these  routines  initialized  to  0.  On 
return  from  each  routine  FOUND  is  checked  for  0  or  1.  If  it  is  0  the  next 
routine  is  called.  If  it  is  1  this  means  the  routine  recognized  a  token,  so 
GTOKEN  returns  to  its  calling  routine.  If  the  recognition  routine  does  not 
recognize  a  token,  it  calls  a  routine  called  BACKUP  so  that  the  next  recog¬ 
nition  routine  will  begin  its  scan  of  the  source  code  at  the  same  position 
that  the  previous  routine  did. 

The  first  routine  called  to  attempt  to  recognize  a  token  is  STRING. 
STRING  first  skips  past  any  blanks  or  commas.  STRING  looks  for  a  string 
which  is  anything  enclosed  in  quotes.  If  a  string  is  found  the  subroutine 
ADDSTR  is  called  to  add  the  string  to  the  string  table.  ADDSTR  returns  the 
index  of  where  the  string  was  added  into  the  table.  STRING  adds  this  index 
to  10000  to  generate  the  numeric  token.  FOUND  is  set  to  1  and  a  return  is 
made; 

COMMENT  is  called  next,  which  attempts  to  recognize  a  comment  which  is 
anything  enclosed  in  number  signs  (#).  If  a  comment  is  found,  FOUND  Is  set 
to  1  and  a  return  made.  GTOKEN  does  not  return  when  a  comment  is  found. 
Because  comments  are  intended  only  for  the  writer  of  the  CODAP  code  they  are 
ignored  by  the  interpreter.  GTOKEN  will  start  the  series  of  calls  to  the 


recognition  routines  again  beginning  with  STRING  after  finding  a  comment. 
No  numeric  token  is  generated  for  comments. 

CNSTNT  is  called  next  to  attempt  to  identify  a  constant  which  is  a 
string  of  digits  that  may  include  a  decimal  point.  If  a  constant  is  found 
it  is  converted  into  numeric  form,  and  ADDCON  is  called  to  add  it  to  the  con¬ 
stant  table.  ADDCON  returns  to  the  index  of  where  the  constant  was  added 
into  the  table.  CNSTNT  adds  this  index  to  20000  to  generate  the  numeric 
token.  FOUND  is  set  to  1  and  a  return  made. 

RELOP  is  called  next  which  attempts  to  recognize  a  relational  operator. 
Relational  operators  are  things  such  as  .EQ.,  ,NE.,  .LT.,  and  =  .  If  a  rela¬ 
tional  operator  is  recognized  it  is  assigned  a  numeric  token  of  30000  plus. 
The  exact  numeric  token  assignments  can  be  seen  in  appendix. 

BOOLOP  is  called  to  recognize  boolean  operators.  Boolean  pperators  are 
.AND.,  k,  .OR.,  and  {  .  If  a  boolean  operator  is  recognized  it  is  assigned  a 
numeric  token  of  40000  plus  as  indicated  in  appendix. 

DELIM  attempts  to  recognize  the  next  token  as  a  delimiter.  Delimiters 
are:  and  ;.  If  a  delimiter  is  found  it  is  assigned  a 

numeric  token  of  50000  plus. 

FUNC  attempts  to  recognize  functions.  The  functions  are;  LOG,  SQRT , 
ACUM,  DCUM  and  so  forth.  If  a  function  is  found  it  is  assigned  a  numeric 
token  of  60000  plus. 

SYSVAR  attempts  to  recognize  system  variables  which  are:  the  system 
groups  produced  by  the  clustering  program  such  as  G1  and  G5,  history  vari¬ 
ables  that  are  input  by  INPSTD  such  as  HI  and  H4,  task  variables  such  as  T1 
and  T4,  secondary  variables  such  as  SI  and  S3,  incumbents  such  as  II  and  12, 
and  computed  variables  such  as  RAWSUM  and  SIMCOF.  If  one  of  these  is  recog¬ 
nized  it  is  assigned  a  numeric  value  of  70000  plus  for  computed  variables, 
80000  plus  the  integer  portion  of  the  history  variable  for  history  vari¬ 
ables,  90000  plus  the  integer  portion  of  the  task  variable  for  task  vari¬ 
ables,  100000  plus  the  integer  portion  of  the  secondary  variable  for  second¬ 
ary  variables,  110000  plus  the  integer  portion  of  the  group  variable  for 
group  variables,  and  160000  plus  the  integer  portion  of  the  incumbent  for 
incumbents.  Groups  can  take  on  the  range  110000-139999  and  incumbents  are 
anything  160000  or  greater. 

KEYWRD  is  called  next  to  look  for  a  key  word.  Key  words  are  words  that 
have  special  meaning  to  the  CODAP  language  such  as  CREATE,  AVALUE,  IF,  and 
THEN. 

ID.  is  called  to  check  for  an  id.  Since  this  is  the  last  routine  called 
the  next  token  has  to  be  an  id  unless  it  is  a  character  that  is  not  meaning¬ 
ful  to  CODAP80.  If  an  id  is  found  BLDWST  is  called  to  add  the  id  to  the 
WST.  BLDWST  is  further  explained  in  the  next  chapter.  BLDWST  returns  the 
index  of  where  the  id  was  added  into  the  table.  ID  adds  this  index  to 
150000  to  generate  the  numeric  token. 

If  none  of  these  routines  can  recognize  the  token  it  means  an  invalid 
character  was  entered  in  the  source  code.  GTOKEN  will  then  skip  that 


character  after  printing  an  error  message  and  begin  the  calls  to  the 
recognition  routines  again. 


THE  SYMBOL  TABLE 
AND  ITS  ACCESS  ROUTINES 

The  two  symbol  tables  used  in  the  interpreter  are  used  to  keep  track  of 
where  all  information  is  located.  The  PST  keeps  track  of  all  information  on 
the  permanent  files  and  is  kept  on  a  disk  file.  The  WST  keeps  track  of 
where  any  information  needed  within  a  single  CODAP80  program  is  located. 
The  WST  may  point  to  information  on  the  permanent  files  or  to  information  on 
the  scratch  files.  The  WST  is  created  in  a  table  in  core. 

The  PST  is  initially  created  by  INPSTD  and  contains  11  entries  each 
with  12  elements. 

The  headings  on  each  of  the  12  elements  do  not  really  apply  to  the 
first  11  entries,  only  to  the  12th  and  following  entries,  which  keep  track 
of  data  that  is  added  to  the  files  through  the  use  of  the  CODAP80  language. 

Element  4  of  entries  1-5  is  used  to  keep  track  of  where  the  next  free 
labels  and  records  are  located.  Entries  1-3  give  information  about  the  his¬ 
tory,  task  and  secondary  records  established  by  INPSTD.  For  each  of  the  3 
entries,  element  6  tells  the  number  of  variables  in  the  database,  element  10 
gives  the  record  number  of  the  first  record  of  that  type  variable,  and  ele¬ 
ment  11  gives  the  record  number  of  where  the  first  remark  is  stored.  Each 
variable  in  the  system  has  a  240  character  string  called  a  remark  associated 
with  it.  Entry  4  gives  information  about  the  groups  produced  by  the  clus¬ 
tering  program;  element  6  gives  the  number  of  groups  produced  and  element  10 
gives  the  record  number  of  where  the  first  of  the  two  vectors,  LOWHSN  and 
HIGHHSN,  is  stored.  The  fifth  entry  has  the  number  of  incumbents  for  the 
study,  in  element  6,  the  sixth  entry  gives  in  elements  1-3  the  Hollerith 
value  in  3A4  format  of  the  study  id  associated  with  a  database.  The  seventh 
through  ninth  entries  give  the  record  number  of  each  of  the  three  computed 
variables . 

For  the  12th  and  following  entries  of  the  PST  is  where  information 
added  to  the  files  is  kept  track  of.  Elements  1-3  hold  the  source  code  id 
in  3A4  format.  A  routine  called  SQUASH  is  called  to  convert  4  A1  words  to 
one  A4  word  to  get  the  id  into  3A4  format.  This  is  the  only  routine  in  the 
system  that  is  machine  dependent;  it  assumes  a  32  bit  word.  The  fourth  ele¬ 
ment  holds  a  link  in  the  chain  or  linked  list  and  is  used  will  be  as  unique 
as  possible  for  each  different  id.  The  hash  code  points  to  a  position  in  an 
array  and  the  number  in  that  array  points  to  a  proper  entry  in  the  symbol 
table.  To  add  an  id  to  the  table  its  hash  code  is  generated;  the  code 
points  to  an  element  of  the  array.  This  element  is  set  to  point  to  the  next 
free  space  in  the  symbol  table.  A  pointer  that  keeps  track  of  where  the 
next  free  space  is  incremented.  To  retrieve  an  id  from  the  symbol  table  its 
hash  code  is  generated.  The  code  will  be  the  same  as  was  generated  when  the 
id  was  added  to  the  symbol  table.  The  code  then  points  to  the  position  in 
the  array  of  pointers  that  points  to  the  proper  entry  in  the  symbol  table. 


CODAP80  INTREPRETER  TOKENS  AND  THEIR  NUMERIC  VALUES 
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CODAP80  INTERPRETER  TOKENS  AND  THEIR  NUMERIC  VALUES 

SORTED  NUMERICALLY 
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Routines  that  ares  used  to  access  the  symbol  tables  are  WRTRVE  (WST 
retrieve),  PRTRVE  (PST  retrieve),  WRTV12  (WST  retrieve  length  12),  WSTADD 
(add  to  the  WST),  WSTREP  (replace  an  entry  of  the  WST),  and  WSTSUB  (subtract 
and  entry  of  the  WST).  WRTRVE  will  return  the  first  11  elements  of  an  entry 
based  on  an  index  number  passed  to  it.  Since  the  numeric  tokens  for  ids 
contain  the  index  number  it  is  a  simple  matter  to  compute  the  index  number 
from  the  tdken  when  the  token's  entry  in  the  WST  needs  to  be  retrieved. 
WRTV12  does  the  same  thing  that  WRTRVE  does  except  that  it  retrieves  all  12 
elements  of  each  entry.  WSTADD  will  add  a  new  entry  to  the  WST  based  on  an 
input  index  number.  WSTREP  will  replace  an  entry  of  the  WST  based  on  an 
input  index  number.  RPTRVE  will  retrieve  an  entry  of  the  PST  given  the 
source  code  id  in  3A4  format  and  its  hash  code.  PRTRVE  has  to  search 
through  the  linked  list  to  find  an  id  if  there  is  a  collision,  but  WRTRVE 
and  WRTV12  do  not  have  to  because  the  index  they  get  points  directly  to  the 
proper  entry  in  the  symbol  table.  This  is  one  of  the  advantages  of  the 
numeric  tokens  because  they  make  it  possible  to  get  to  resolve  collisions  in 
hash  values.  The  fifth  element  gives  the  type  of  data  represented,  a  1 
means  a  row,  a  2  a  group,  a  3  a  module,  and  a  4  a  column.  The  sixth  element 
contains  the  length  of  the  vector.  Elements  7-9  contain  the  module  or  group 
that  a  column  or  row  was  created  for,  or  is  blank  if  the  entry  represents  a 
module  or  group.  Element  10  gives  the  record  number  of  the  vector.  Element 
11  gives  the  record  number  of  its  associated  remark.  Element  12  is  the 
label  number  that  points  to  the  symbol  table. 

The  WST  is  created  during  each  run  by  first  calling  the  subroutine 
W  SET  UP  (WST  set  up)  to  copy  the  first  11  entries  from  the  PST  to  the  WST. 
As  ids  are  encoutnered  by  GTOKEN  they  are  added  to  the  WST  by  calling  the 
subroutine  BLDWST.  BLDWST  first  checks  to  see  if  the  id  is  already  present 
in  the  PST,  if  it  is  that  entry  from  the  PST  is  copied  into  the  WST.  If  it 
is  not  the  id  is  added  to  the  WST  by  filling  in  the  id  (elements  1-3),  and 
the  chain  (element  4),  and  the  membership  (elements  7-9).  The  syntax  analy¬ 
sis  routine  that  called  GTOKEN  will  set  the  type,  membership,  and  remark 
record  number  elements.  The  length,  involves  taking  the  Hollerith  value  of 
the  source  code  id  and  treating  it  as  a  number,  then  computing  a  hash  code 
that  will  be  as  unique  as  possible  for  each  different  id.  This  involves 
taking  the  Hollerith  value  of  the  source  code  id  information  from  the  WST 
without  any  search. 

The  access  routines  have  been  set  up  so  that  any  time  a  module  needs 
information  from  a  symbol  table  it  does  not  deal  directly  with  the  symbol 
table.  This  should  prevent  problems  that  might  develop  if  a  module  made  an 
incorrect  change  to  a  symbol  table;  which  would  then  affect  other  modules. 
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FORTRAN  FG  PROC 

COMPILE,  LINK  EDIT  AND  GO  PROCEDURE 
FOR  THE  G1  FORTRAN  COMPILER 


//FG  EXEC  PGM»IEYF0RT,REGI0*>192K 
//SYSPRINT  DD  SYSOUT-A 
//SYSPUNCH  DO  SYSOUT-B 

//SYSUN  OD  DSNAME-4L0ADSET,D1SP-(M00,PASS),UNIT-SYSSQ, 

//  SPACE* <80,  <200, 100)  ,RLSE)  .0C8-8LKSIZE-80 

/* 

//LKED  EXEC  PGM-I EWL.REG ION- 128K,PARM-(XREF,IET,LI ST) 

//SYSLIB  00  OSNAME-S YS 1 .FORTL 18,01 SP»SHR 

//SYSLMCO  DO  DSNAME*4GOSET(J4AIN)  ,D  I  SP*( NEW, PASS)  .UNIT-SYSDA, 

//  SPACE*< 1024,(20, 10, t) ,RLSE) ,0C8*8LKSIZE* 1024 

//SYSPRINT  00  SYSOUT-A 

//SYSUT1  DO  DSNAME-4 SYSUTI, UNI T-SYSDA, SPACE- ( )02<, <20,10) ,RLSE) , 

//  DCB*BLKSlZE«1024 

//SYSUN  00  DSNAME*4  LOAOSET  ,0 1  SP=  <  OLD  .DELETE) 

//  00  DDNAME-SYSIN 

/» 

//GO  EXEC  PGM-».LKE0.SYSLM00 
//FT05F00I  OD  OONAME-SYSIN 
//FT06F00I  00  SYSOUT-A 
/ /FT07FQ0 1  DO  SYSOUT-B 
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CODAP80  FILE  LAYOUTS 


CONTROL  AND  DATA  FILE  LAYOUTS 


SAA*»L£DATA6 00000700 I000400050003Y 
HH.H.HTSTSTSTSTS 

•• 

HI  -SEX; 

H2  -ACS; 

H3  -YEARS  ON  JOS; 

H4  -INC  IMS ENT  10; 

T1  -SU80UE  VIOLENT  INMATES; 

T2  -SHAKE  DOWN  IM4ATES; 

T3  -SHAKE  OOWN  VISITORS; 

T*  -ESCORT  lf#»ATES; 

T5  -TESTIFY  IN  COURT; 

51  -SECONDARY  -  SU80UE  VIOLENT  INMATES; 

52  -SECONOARY  -  SHAKE  OOWN  IWATES; 

53  -SECONOARY  -  SHAKE  OOWN  VISITORS; 

54  -SECONOARY  -  ESCORT  IH4ATES; 

S3  -SECONOARY  -  TESTIFY  IN  COURT; 

M 

HI  l-MALE;  2-FEMALE; 

SI -S3  1-00;  2-ASSIST;  3-SUPERVISE; 

«• 


'219  117  1111220 
14)19212420  222) 

1  1630  33430  0 
127  344  41310  63 
123  231  1122310 
13330642710  0  0 

2  1170  0  223231 


VARCOM  LAYOUT 


RECORD  CONTENTS 

RECORD  *  WORD  61 


1  I  3| SEX  |  |  !  •  I  |  | 


2  |  3 | AGE  | 


3  |  12 | YEAR |S  ON |  JOB |  |  | 


4  I  12 | INCH | M8EN | T  ID|  I  | 


S  |  22 | SU80 | UE  V | IOLE | NT  I | NMAT | ES  | 


6  |  1 8 | SHAK [ £  00 ( WN  I | NMAT | ES  |  | 


7  |  19 | SHAK | 6  00 | WN  V|ISJT|0RS  I  | 


8  I  14 | ESCO | RT  1 1 NMAT I ES  f  I 


9  |  16 | TEST | I FY  | IN  C|OURT|  |  | 


10  I  34 | SECO | NDAR | Y  •  | SUBD | UE  v|I0LE|NT  I | NMAT | ES  | 


11  |  30 1 SECO | NDAR | Y  -  | SHAK  j  £  DO|WN  1 1 NMAT | ES 


12  |  31 | SECO | NOAR | Y  -  | SHAK | E  DO | WN  V|ISIT|ORS 


13  I  26 1 SECO I NOAR I Y  -  |ESCOjRT  l|NMAT|ES  | 


14  |  2B | SECO | NOAR | Y  -  1  TEST | IFY  | IN  C|OURT| 
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SYNTAB1  LAYOUT 


DECODE  LAYOUT 


RECORD  # 

!  1  .  RECORO  FIELD  CONTENTS' 


V 

1 

2 

3 

4 

5 

6 

■  »*• 

10 

1 

1  .0 

0.0 

2.0 

3.0 

3.0 

7,0 

0.0 

2 

80001 

80001 

3.0 

100001 

100005 

5.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

*  0.0 
0.0 

3 

H 

80001 

80001 

1  .0 

male 

4 

H 

80001 

80001 

2.0 

FEMALE 

s 

S 

100001 

100005 

1.0 

00 

s 

s 

100001 

100005 

2.0 

ASSIST 

7 

s 

100001 

100005 

3.0 

SUPERVISE 
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RECORD  FIELD  CONTENTS 


GRPHSN  LAYOUT 


RECORO  FIELD  CONTENTS  • 


